home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: maney@mcs.com (Martin J. Maney)
- Newsgroups: comp.std.c++
- Subject: Re: Article for comp.std.c++: Eliminating #ifdef: if const
- Date: 23 Feb 1996 15:55:14 GMT
- Organization: MCSNet Services
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4gjerl$rg4@Venus.mcs.com>
- References: <199602160807.IAA06126@condor.ukc.ac.uk> <4gb0a4$sa3@fido.asd.sgi.com> <4giddp$7q6@mulga.cs.mu.OZ.AU>
- NNTP-Posting-Host: taumet.eng.sun.com
- X-Newsreader: TIN [version 1.2 PL2 (KSD)]
- Originator: clamage@taumet
-
- Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
- > shankar@mti.mti.sgi.com (Shankar Unni) writes:
-
- > >Often, an #ifdef covers just a small part of an expression that may be
- > >different between different environments, or some such small differences:
- > >
- > > if (some condition) {
- > >#ifdef SOMEIMPL
- > > if (some other condition) {
- > >#endif /* SOMEIMPL */
- > > /* code */
- > > /* code */
- > > /* code */
- > >#ifdef SOMEIMPL
- > > }
- > >#endif /* SOMEIMPL */
- > > }
-
- > But with `if const', your 11 lines of code could be rewritten as either
-
- > if (some condition) {
- > if (SOMEIMPL && some other condition) {
- > /* code */
- > /* code */
- > /* code */
- > }
- > }
-
- > (7 lines of code)
-
- Of course it's a little unfair to pick on the specific features of the
- example, but I can no longer resist the temptation to point out that all
- of these are simply awful ways to deal with this sort of target
- dependency. What you truly want in these cases is to replace the
- platform-dependent hackery with
-
- if (implementation_defined_test())
- {
- ...
- }
-
- And let implementation_defined_test() be defined in whatever place you
- like to collect portability [sic] stuff. In C one might have to choose
- between a function-like macro that could be unsafe and a function that
- might be too costly, but in C++ you can have hte best of both worlds if
- you make it an inline function.
-
- Again: I realize there are other applications for the proposed idea; I
- encourage its supporters to present them and make a better case for this
- feature. But this example strikes me as an argument _against_ the
- feature on the grounds that it encourages what I am happy to call a
- simply awful coding style.
-
- > Both of these solutions have the advantage that the test for `SOMEIMPL'
- > occurs only once, so things will be easier if you later have to change it to
- > `SOMEIMPL || SOMEOTHERIMPL'.
-
- Ditto. Plus the advantage that if this condition is tested for elsewhere
- - and if it isn't now, what are the odds it will be before the program is
- finally retired from service? - the inline function, like the ugly C
- macro, will at least have a chance of getting the change into every piece
- of code that uses it, if only the dependencies are setup correctly. ;-)
-
- > >Duplicating all the code so that each half is precisely correct in its {}
- > >matching is both tedious and error-prone (trying to verify that both parts
- > >of the expression are fixed).
-
- > But fortunately as shown above it would not be required.
-
- Ditto.
-
- > >Also, the #ifdefs serve a purpose in pointing out the fact that this piece
- > >of code is system-dependent. The syntax you propose hides its warts rather
- > >too well, and make it easy for a reader to miss the significant piece of
- > >information that this area of code is system-dependent.
-
- > True, but a convention of using upper-case for SOMEIMPL and similar constants
- > would make such tests stand out.
-
- I will concede that the inline function hides this as well as you want to
- - I used a long, blatant name in my example for precisely this reason.
- But then again, if you don't have to worry about writing the details of
- the target-dependent code all over the place, what difference does it make
- how visible it is or isn't in use?
-
- [ To submit articles: Try just posting with your newsreader.
- If that fails, use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-